The field of the current invention relates to multi-tenant databases. More specifically, the field of the current invention relates to multi-tenant platform as a service (PaaS) and software as a service (SaaS) services (collectively “services” hereinafter).
Services can be offered in public, hybrid, and private cloud environments. Services offered by a service provider may access data stored in a database management system (DBMS) representing computerized information storage and retrieval systems. A DBMS may manage multiple databases, each of which may be owned by different entities. Services may be concurrently subscribed by multiple client organizations (tenants). Thus, the services process data for different tenants. For security and regulatory reasons, tenants demand different degrees of data isolation, which are specified as a “policy element” when the tenant subscribes to the services. It is even more important that the degree of isolation must be seamlessly changeable as security and regulatory requirements change over time. Thus, the service provider needs to implement a multi-tenant architecture for the services allowing data and configuration partitioning so that each tenant receives the appropriate level of data isolation.
There are three current deployment options for managing multi-tenant data. The first deployment option stores tenant data in separate databases, which is the simplest approach to data isolation. Computing resources and application code are generally shared between all tenants on a server, but each tenant has its own set of data that remains logically isolated from data that belongs to all other tenants. Metadata associates each database with the correct tenant, and database security prevents any tenant from accidentally or maliciously accessing other tenants' data. This option, however, tends to lead to higher costs for the service provider for maintaining equipment and backing up tenant data. Hardware costs are also higher than they are under alternative deployment options, as the number of tenants that can be housed on a given database server is limited by the number of databases that the server can support.
The second deployment option involves housing multiple tenants in the same database, with each tenant having its own set of tables and other database artifacts that are grouped into a schema created specifically for the tenant. This approach offers a moderate degree of logical data isolation for security-conscious tenants, though not as much as a completely isolated system would, and can support a larger number of tenants per database server.
A third deployment option involves using the same database and the same set of tables to host multiple tenants' data. A given table can include records from multiple tenants stored in any order, and a tenant identification column associates every record with the appropriate tenant. Of the three options, the shared schema approach has the lowest hardware and backup costs, because it allows one to serve the largest number of tenants per database server.
Converting database deployments from one option to another in a transparent manner is not currently supported, and can only be solved with manual data movement and system downtime. Furthermore, any applications accessing the database currently must be recoded upon such a conversion to reflect the changes to the database.